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Abstract 

The  benefits  of  implementing  a  network-centric  Navy  lie  in  the  new  capabilities  made  possible 
by  enhanced  information  sharing  between  Naval  platforms.  Foremost  is  the  potential  to  enable, 
enhance,  and  automate  dispersed  decision-making  to  support  real-time  critical  mission  areas. 
This  paper  explores  a  network-centric  paradigm-enabled  application:  multi-platform  sensor 
resource  management. 

Sensors  in  platform-centric  Naval  Battle  Forces  are  generally  utilized  and  managed  to  support  a 
single  weapon  or  combat  system.  The  networking  of  combat  systems  and  platforms  creates  an 
information  architecture  in  which  sensor  management  can  shift  to  a  Battle  Force  (BF)  focus.  In 
such  a  network-centric  paradigm,  individual  sensors  address  the  needs  of  the  BF  as  a  whole, 
overcoming  the  platform-centric  architecture,  which  constrains  sensor  use  to  individual 
platform’s  needs.  This  paper  explores  design  concepts  for  an  automated  sensor  resource 
manager  that  tasks  sensors  to  address  BF  needs. 

Network-centric  sensor  resource  management  relies  on  viewing  the  BF  as  a  single  integrated 
interoperable  combat  system  of  systems,  rather  than  a  collection  of  loosely  connected  surface, 
subsurface,  and  air  platforms.  Such  BF  level  thinking  shifts  the  focus  from  legacy  stovepipe 
systems  and  platforms  with  little  or  no  collaboration  incentive,  to  optimized  uses  of  resources 
that  transcend  platform  boundaries  and  span  multi-threat  dimensions.  This  paper  explores 
interoperability  problems  and  root  causes  associated  with  legacy  Naval  BF  sensor  management 
and  poses  solutions  and  considerations  for  a  network-centric  sensor  resource  manager  that 
functions  as  part  of  a  BF  system  of  systems. 

Network-centric  sensor  resource  management  relies  on  the  achievement  of  BF  information 
superiority.  Information  concerning  the  tactical  battle  space  and  BF  resources  (status  & 
capabilities  of  sensors,  weapons,  communications,  etc.)  must  be  timely,  accurate,  and  consistent 
across  the  BF  in  order  to  enable  optimized  sensor  command  and  control.  Another  enabler  is  the 
introduction  of  higher  levels  of  automation  in  link  management  to  support  optimized  inter¬ 
platform  communications.  Additionally,  the  human  interaction  with  automated  decision  aids  is  a 
critical  factor  in  the  design  of  a  BF  sensor  resource  manager.  This  paper  explores  a  BF-wide 
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synchronized  information  database,  intelligent  link  management,  and  human-machine 
interactions  as  necessary  enablers  for  a  network-centric  sensor  resource  manager. 

This  paper  makes  a  case  for  further  study  of  Naval  BF  sensor  resource  management  as  a  viable 
network-centric  application.  An  analysis  is  presented  which  addresses  the  BF’s  need  for  a  sensor 
resource  manager.  The  paper  predicts  enhancements  to  the  BF  based  on  the  adoption  of  an 
automated  sensor  resource  manager  application  into  the  network-centric  Naval  BF. 


I.  Cooperative  Sensor  Resource  Manager  Concept 

The  Naval  BF  is  comprised  of  surface,  subsurface,  and  air  platforms  (such  as  aircraft  carriers, 
cruisers,  destroyers,  frigates,  amphibious  warfare  ships,  surveillance  aircraft,  fighter  jets,  and 
submarines),  sensor  systems,  weapon  systems,  communication  systems,  decision  nodes  (i.e., 
tactical  command  centers  and  planning  commands),  decision  makers,  and  operators. 
Historically,  the  framework  of  the  Naval  BF  has  been  based  on  a  platform-centric  foundation  in 
which  individual  platforms  acted  as  autonomous,  self-sufficient  systems  that  independently 
addressed  mission  areas  (such  as:  theater  air  and  missile  defense,  surface  warfare,  undersea 
warfare,  mine  warfare,  land  attack  warfare,  and  information  warfare).  Collaboration  between 
platforms  was  limited  to  addressing  tactical  missions  in  real-time  or  near-real  time. 
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Figure  1  -  Not  Using  BF  Resources  to  Fullest  Extent 

In  the  platform-centric  Naval  paradigm,  sensor  and  weapon  resourees  have  not  been  used  to  their 
fullest  extent.  This  is  illustrated  in  Figure  1,  in  whieh  the  eoneentrie  eireles  depiet  the  Effeetive 
Engagement  Envelope  (E3)  (the  surrounding  region  in  which  the  platform  can  fire  interceptors  at 
enemy  air  targets)  as  smaller  than  the  maximum  weapons  range  and  sensor  range.  Thus,  the  BE 
is  not  reaping  the  full  benefit  afforded  from  its  sensor  and  weapons  resources.  The  graph  in 
Eigure  1  shows  that  the  point  in  time  when  a  weapon  ean  aetually  be  fired  (must  fall  within  the 
E3  reaction  time)  comes  later  in  the  sensor-to-shooter  timeline  than  the  time  when  the  weapons 
launch  could  have  made  full  use  of  the  weapon’s  maximum  range.  Eigure  I’s  illustrations  are 
foeused  on  a  single  Naval  platform,  but  ean  easily  be  extended  to  a  BE  where  multiple  platforms 
are  involved.  However,  introdueing  more  platforms  eauses  the  problems  and  eomplexities 
involved  in  effectively  managing  BE  resources  to  steadily  increase. 
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The  payoff,  or  gain  in  battle  space,  of  having  network  centric  Navy  Battle  Forces  (BF)  as 
opposed  to  platform  centric  single  ship  war  fighters  is  not  being  realized.  The  addition  of  more 
platforms  and  subsequently  more  sensors  and  weapon  systems  should  afford  the  BF  such 
benefits  as  increased  detection  ranges,  improvements  in  engagements  with  less  resource 
depletion,  and  decreases  in  sensor- to- shooter  timelines.  However,  the  additional  BF  resources 
are  introducing  new  and  greater  complexities  into  the  BF  problem  space,  resulting  in: 
information  overload,  greater  decision  complexity,  a  reduced  quality  and  often  inconsistent  track 
picture,  latencies  in  response  times,  and  increased  competition  for  resource  allocations.  The 
combination  of  the  addition  of  BF  resources  and  the  growing  threat  environment  is  causing  the 
BF  problem  space  to  grow  more  rapidly  than  the  payoff  space. 

This  paper  focuses  on  aspects  of  cooperative  sensor  resource  management — managing  BF 
sensors  on  disparate  Naval  platforms  from  a  BF  perspective.  The  Cooperative  Sensor  Resource 
Manager  (SRM)  is  envisioned  as  a  command  and  control  system  for  the  Naval  Battle  Force  (BF) 
that  manages  sensor  resources  on  multiple  platforms  (ships  and  aircraft)  in  a  collaborative 
manner.  The  SRM  concept  involves  a  set  of  tightly  coupled  and  networked  distributed 
processors  (distributed  across  BF  platforms)  that  synchronize  force-level  command  and  control 
of  sensor  resources  across  the  BF. 

Automating  Sensor  Management 

Sensor  management  is  a  process  for  improving  or  optimizing  the  measurement  process  in  sensor 
systems.  The  process  of  optimizing  the  control  of  the  measurement  process  is  one  of  the  least 
developed  elements  in  sensor  systems.  Some  research  has  been  performed  to  deal  with  the 
optimization  of  detection  and  tracking  functions  in  isolation  of  each  other.  Little  research  has 
been  performed  that  takes  an  overall  systematic  approach  to  the  composite  measurement/ 
tracking/situation  assessment  problem.  Even  less  research  has  been  performed  that  examines 
solutions  to  managing  sensors  on  geographically  dispersed  platforms. 

In  order  to  make  the  case  for  automating  the  sensor  management  function  and  expanding  the 
function  from  managing  sensors  on  a  single  platform  to  a  BF  of  multiple  platforms,  the  projected 
system  performance  of  doing  so,  must  be  addressed.  The  following  lists  projected  gains  and 
methods  for  achieving  the  gains  from  automating  sensor  resource  management. 

[1]  Effective  Use  of  Limited  Sensor  Resources 

•  Tailoring  different  sensor  capabilities  to  different  mission  needs 

•  Cueing  sensors  based  on  input  from  other  sensors 

•  Redirecting  agile  aperture  sensors  to  search  in  particular  sectors  or  revisit  tracks 

•  Managing  modes  of  multi-mode  sensors  for  different  tactical  applications 

•  Controlling  scan  rate  according  to  information  needs 

[2]  Effective  use  of  Limited  Operator  Resources 

•  Limiting  operator  workload  by  limiting  amount  of  non-tactical  information  displayed 

•  Automating  lower  level  control  functions 

•  Suppressing  sensor-specific  details  from  Operator  displays  and  decision-loops 

•  Easing  burden  of  Operator  interfaces  without  limiting  flexibility  of  human  control 

[3]  Track  Picture  Advances 

•  Enabling  automated  track  quality  management  through  sensor  optimization 
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•  Recognizing  and  correcting  for  track  degradation  in  an  automated  fashion  &  in  real-time 

•  Scheduling  track  updates  only  as  required  for  maintaining  track  quality  within  bounds 

•  Assigning  (&  updating)  track  quality  goals  based  on  each  track’s  tactical  significance 

•  Tailoring  sensor  functions  to  correct  for  tracks  in  dense  or  obtuse  environments 

•  Handling  target  maneuvers  by  using  higher-order  processing  algorithms  and  techniques 

•  Improving  tracking  by  adaptively  modifying  processes  in  real-time,  such  as  modifying  the 
tracking  filter  or  shortening  the  target  revisit  time  to  minimize  model  mismatch 

[4]  Sensor  Fusion  and  Synergism 

•  Controlling  different  sensors  based  on  their  strengths  to  cooperatively  support  overall  goal 

•  Intra-platform  and  inter-platform  cueing  of  particular  sensors  based  on  tracks  maintained  by 
other  sensors  (one  sensor  detects,  while  another  tracks) 

•  Minimizing  or  eliminating  active  sensing  (active  radar  radiation)  by  using  passive  sensors  for 
search  roles  (while  maintaining  sufficient  tracking  accuracy) 

•  Improving  discrimination  techniques  by  optimizing  sensor  use 

[5]  Situation  Assessment  Improvements 

•  Improving  process  of  situation  assessment  by  automatically  shifting  from  kinematic  tracking 
to  generating  target  inferences  (i.e.,  target  intent,  etc.)  -  enabling  feedback  link  between 
automated  situation  assessment  function  and  sensors  (to  improve  data  collection) 

•  Efficiently  using  sensors  for  tactical  needs  -  managing  sensors  based  on  tactically  important 
data  collection  schemas 

•  Filling  in  missing  information  -  using  sensors  to  collect  data  to  confirm  tactical  inferences 
(identified  detected  targets,  resolve  clustered  targets,  etc.) 

[6]  Fire  Control  Support 

•  Enabling  local  and  remote  sensor  data  collection  tasking  based  on  weapon’s  needs 

•  Enabling  inter-platform  engagement  coordination  strategies  (possibly  engagement  on  remote 
and  forward  pass) 


Micro  vs.  Macro  Sensor  Management 


Figure  2  -  Sensor  Elements 


Two  aspects  of  sensor  management  exist:  “macro”  management  (the  determination  of  WHAT 
tasks  sensors  should  perform)  and  “micro”  management  (the  determination  of  HOW  a  particular 
sensor  will  perform  its  tasking).  This  section  makes  a  case  for  dividing  these  functions  by 
associating  the  macro  management  with  each  particular  sensor  and  allocating  the  macro 
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management  to  the  Cooperative  SRM  system.  This  allocation  simplifies  the  SRM’s  difficult  task 
of  determining  sensor  tasking  for  noncollocated  and  varying  sensors.  It  also  supports  the 
inherent  close  coupling  of  the  micro  management  function  with  the  sensors. 

Figure  2  illustrates  this  concept:  the  sensor  system  consists  of  the  measurement  device 
(illustrated  as  a  radar)  as  well  as  raw  measurement-level  data  processing  and  a  micro-sensor 
manager  that  translates  macro-level  commands  into  sensor-specific  adjustments  that  fulfill  the 
commands.  The  sensor  elements  are  shown  inside  the  box  marked  “radar  system”.  The 
Cooperative  SRM  performs  macro  sensor  management  functions  that  determine  what  tasks  each 
sensor  should  perform,  and  avoids  determining  how  each  specific  sensor  will  accomplish  tasks. 


Cooperative  SRM  Conceptual  Design 
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Figure  3  -  Automated  Cooperative  SRM  Concept 
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The  SRM’s  external  interfaces  must  be  viewed  as  a  set  of  interfaces — one  on  each  platform,  with 
the  following  functionality: 

[1]  Sending  macro-level  commands  or  “sensor  tasking”  to  the  sensors  -  involves  routing  tasking 
to  correct  sensors  &  ensuring  tasking  is  correctly  received 
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[2]  Managing  the  received  sensor  data  -  keeping  track  of  sensor  data  (&  sensor  status  data) — 
time-stamping,  checking  for  error,  keeping  track  of  error,  storing,  distributing  to  all  platforms, 
routing  to  C4I  systems  within  each  platform 

[3]  Translating  information  for  the  various  types  of  sensors  —  providing  the  translation  layer  that 
can  handle  various  data  types  and  protocols. 

Figure  3  illustrates  an  example  of  the  SRM  functioning  on  two  platforms  and  interacting  with  the 
resident  sensors  and  C4I  systems.  The  SRM  has  the  responsibility  to  develop  macro-level  sensor 
commands.  In  order  to  develop  these  commands,  it  must  keep  track  of  sensor  status  and 
determine  the  sensor  data  needs  of  the  BF.  The  concept  shown  below  shows  a  BF  information 
database,  a  situation  assessment  function,  and  a  link  manager — all  of  which  are  external  to  the 
SRM.  These  elements  are  addressed  later  in  this  paper.  Also  illustrated  are  multiple  sensors 
with  their  associated  sensor  data  processors  and  micro  managers  on  each  platform. 


Rest  of  CMC 


Figure  4  -  Example  of  SRM  Functionality 

The  top-level  functionality  of  the  SRM  conceptual  design  is  shown  in  Figure  4.  This  diagram 
shows  the  interfaces  between  functions  A-J.  “CMC”  in  this  diagram  refers  to  the  Cooperative 
Management  Capability,  the  parent  system  that  includes  an  automated  link  manager,  and 
automated  weapons  resource  manager,  as  well  as  the  SRM.  Besides  external  interfaces  to  the 
rest  of  CMC  and  to  Operators  and  the  function  of  storing  data,  the  key  functions  of  the  SRM  are 
determining  sensor  tasks  from  the  situation/threat  input  and  data  input;  allocating  tasks  to  sensors 
based  on  their  capabilities,  availability  and  status;  synchronizing  the  decisions  among  platforms; 
and  tasking  the  sensors. 

II.  Existing  Challenges  to  Achieving  NCW/Cooperative  SRM 

This  section  explores  the  Naval  BF  problem  space  that  inhibits  the  achievement  of  cooperative 
sensor  resource  management  and  network  centric  warfare  in  general. 
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[1]  The  shift  from  platform-centric  to  network-centric  has  not  completely  taken  place: 
network-centric  concepts  are  not  “designed-in”  to  systems  yet. 

Current  Naval  systems  are  not  designed  from  a  network  centric  (multi-platform)  point  of  view. 
Such  network-centric  design  is  necessarily  a  top  down  process — starting  with  a  design  for  Battle 
Force  level  and  decomposing  or  allocating  force-level  requirements  to  the  BF  elements  (or 
platforms/systems).  The  historical  approach  has  focused  on  the  design  of  each  BF  element 
individually  and  has  attempted  to  achieve  interoperability  in  an  “after-the-fact”  method  by 
focusing  on  interfaces  between  the  elements.  By  not  “designing-in”  Force-level  requirements, 
network-centric  applications  such  as  the  SRM  are  not  possible.  A  force-level  vision  is  necessary 
to  conceive  and  design  the  SRM — whose  functionality  and  system  boundary  spans  BF  platforms. 

[2]  The  requirements  for  BF  resource  management  are  not  specified  from  a  BF-level 
perspective. 

Many  naval  interoperability  problems  are  the  result  of  problems  involving  requirements 
definition  and  implementation.  Requirements  for  legacy,  current,  and  future  systems  are  not 
defined  from  a  Battle  Force  (BF)  perspective.  The  requirements  in  many  cases  are  incomplete, 
inadequately  or  inappropriately  defined,  and/or  stale.  The  underlying  fundamental  bases  of 
requirements  are  frequently  misunderstood.  Additionally,  requirements  are  not  always 
implemented  as  intended  or  as  specified  and  are  sometimes  not  implemented  at  all.  As  an 
example,  there  are  no  requirements  at  the  BF-level  for  sensor  resource  management. 

[3]  The  Navy’s  acquisition  and  program  management  practices  prevent  network-centric 
warfare  (and  thus  BF-level  sensor  management). 

The  old  saying  that  too  many  cooks  spoil  the  broth  is  exemplified  by  the  way  that  Naval 
command  and  control  systems  are  defined,  designed,  and  procured.  Platforms  are  developed  in 
closed,  stove  piped  environments  with  the  focus  on  the  platform  level  systems,  e.g.,  ACDS, 
AEGIS,  SSDS  MK2.  Sensor  resource  management  functionality  is  embedded  in  such  combat 
systems  and  associated  sensor  systems  and  is  therefore  acquired  and  managed  from  a  platform 
perspective.  Another  program  management  problem  involves  the  process  for  making  changes  to 
requirements  and  systems.  Coordinating  the  implementation  of  requirements  changes  is  poorly 
managed — no  organization  is  responsible  for  the  funding  needed  to  bring  about  such  a  process. 

[4]  Legacy  system  constraints  prevent  an  evolution  to  a  network-centric  Navy. 

Legacy  system  limitations  constitute  a  huge  challenge  to  achieving  the  collaborative 
management  of  BF  resources.  Many  new  developments  and  solutions  that  might  provide 
improvements  are  limited  or  effectively  precluded  by  legacy  paradigms,  methods,  and/or 
systems.  These  legacy  constraints  manifest  themselves  through:  systems  that  are  too  expensive 
to  replace  or  remove;  agreements  with  Joint  or  Allied  forces  that  prevent  their  removal;  and 
programmatic  “rice  bowls”  whose  survival  depends  on  the  continued  existence  of  these  legacy 
system  elements.  Cooperative  sensor  resource  management  is  affected  by  the  following  legacy 
constraints: 

•  Legacy  link  formats  (Link  11,  16,  and  CEC  become  data  precision  bottlenecks  for  both  track 
and  ship  position  data — causing  a  huge  problem  for  the  fusion  of  multi-platform  sensor  data.) 

•  Legacy  use  of  bandwidth  (Does  not  support  sufficient  data  exchange  to  achieve  shared 
situational  awareness  necessary  for  inter-platform  real-time  sensor  feedback  control  loops) 

•  Legacy  communication  hardware  (Limits  data  exchange  speed/accuracy— better  technology 
exists  but  cannot  be  used  because  transition  is  too  difficult  (installation  across  platforms) 
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•  Outdated  and  multiple  combat  system  baselines  (AEGIS  Baseline  4  &  ACDS  Block  0  still  in 
operation —  Navy  has  found  it  difficult  to  fund  timely  retirement/update  of  older  combat 
system  variants,  hobbling  Force-level  resource  management  capability  evolution.) 

[5]  Existing  sensor  command  and  control  mechanisms  rely  too  heavily  on  manual 
participation. 

•  Operators  have  to  deal  with  lower  level  sensor  details  than  is  efficient  for  making  timely  and 
accurate  decisions. 

•  No  effective  automated  decision  aids  exist  for  supporting  the  management  of  sensors  across 
BE  platforms. 

•  The  complexity  of  missions  and  operational  environment  produce  a  multitude  of  options  and 
an  overload  of  information,  leaving  Operators  with  too  much  information  and  too  little  time 
to  make  effective  decisions. 

•  The  existing  communication  architecture  does  not  provide  a  means  of  distributing  the 
information  (such  as  sensor  status  &  commands)  across  the  BE  to  support  cooperative  sensor 
resource  management  and  other  NCW  concepts. 

[6]  The  existing  information  architecture  constrains  cooperative  BE  resource  management. 

•  The  existing  communication  architecture  does  not  provide  a  means  of  distributing  the 
information  (such  as  sensor  status  &  commands)  across  the  BE  to  support  cooperative  sensor 
resource  management  and  other  NCW  concepts. 

•  The  existing  infostructure  prohibits  level  4  data  fusion  or  the  feedback  loop  of  fusing  data  to 
produce  a  tactical  picture  and  using  information  from  the  picture  to  re-task  sensors  to 
improve  the  picture  in  real-time. 

•  The  infostructure  relies  on  disparate  C2  processing  methods  across  platforms  (due  to 
evolution  of  various  legacy  combat  systems) — this  lack  of  commonality  prevents  BE 
synchronization  in  terms  of  shared  awareness  and  collaborative  capabilities. 

•  A  lack  of  standardization  in  Naval  information  systems  causes  complex  interfaces;  multiple 
data  formats;  differences  in  doctrine,  algorithms,  &  processes;  lack  of  a  common  BE  lexicon; 
lack  of  common  time/  navigation/data  registration  standards;  etc. 

•  There  is  a  symbiotic  or  closely  coupled  relationship  between  the  command  and  control  of 
sensor  resources  and  the  inherent  BE  infostructure:  the  structure  of  how  information  flows 
through  the  BE  poses  constraints  on  how  commands  and  tasks  can  be  executed.  As  an 
example,  the  growth  in  complexity  of  the  threat  space  and  its  environment  demands  more 
timely  and  error-free  information  sharing  among  BE  decision  nodes.  The  BE  framework 
must  evolve  in  response  to  this  growth. 

•  Information  management  throughout  the  BE  has  not  been  considered  (or  designed)  from  a 
network-centric,  system-of-systems  perspective.  For  example,  databases  or  track  files  are 
designed  on  a  platform  or  system  basis — and  as  a  result,  databases  are  not  synchronized  and 
thus  data  disparities  and  inconsistencies  among  platforms  exist. 

III.  Required  Enablers  for  Cooperative  Sensor  Resource  Management 

The  Cooperative  SRM  requires  the  achievement  of  a  network-centric  warfare  paradigm. 
Inherent  to  NCW  is  interoperability  between  BE  platforms.  This  section  addresses  necessary 
enablers  required  to  achieve  the  cooperative  SRM  concept.  The  first  enabler  introduced  is  the 
establishment  of  a  common,  synchronized  BE  information  database.  The  second  enabler 
described  is  an  automated  link  manager.  Finally,  this  section  addresses  higher  levels  of 
automation  in  the  Operator’s  interaction  with  the  Cooperative  SRM. 
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COP/CTP/FCP  BF  Information  Database 

The  SRM  conceptual  design  was  illustrated  in  Figure  3.  An  element  of  this  illustration  was  the 
COP/CTP/FCP  BF  Information  Database.  This  element  is  based  on  the  collapse  of  the  COP, 
CTP,  and  FCP  into  a  common  database  that  is  synchronized  across  BF  platforms.  This  concept 
is  integral  to  the  achievement  of  both  information  superiority  as  well  as  establishing  a 
Cooperative  SRM.  Information  superiority  is  achieved  when  the  Naval  BF  gains  a  superior 
information  position  relative  to  its  enemies  by  establishing  and  maintaining  shared  and  consistent 
battle  space  awareness  across  the  BF.  Information  in  the  BF  is  currently  divided  into  three 
categories  as  shown  in  Figure  5:  the  Common  Operational  Picture  (COP),  the  Common  Tactical 
Picture  (CTP),  and  the  Fire  Control  Picture  (FCP).  Information  from  all  three  categories  are 
relevant  to  the  effective  and  efficient  management  of  BF  resources  as  well  as  to  addressing  BF 
threats  and  operations. 

The  COP  consists  of  non-real-time  tactical  information  used  for  mission  planning  and  force 
management,  such  as  blue  and  red  Courses  of  Action  (COAs),  a  priori  knowledge  of  the  enemy, 
and  cultural,  political,  and  geographical  features.  The  CTP  consists  of  near-real- time  tactical 
data  and  information  used  for  cueing  and  managing  BF  resources  (such  as  sensors, 
communications,  and  weapons).  The  FCP  is  the  collection  of  real-time  fire  control  quality 
data/measurements  used  to  support  weapons  during  launch  and  in-flight. 

The  challenge  involved  in  attaining  tactical  information  superiority  lies  in  taking  full  advantage 
of  the  capabilities  of  the  distributed  sensors  and  communication  resources  to  best  fulfill  the 
dynamically  changing  needs  of  the  large  set  of  distributed  information  users.  Without 
implementing  the  SRM  concept,  sensors  and  other  BF  resources  (links,  weapons,  etc.)  will 
continue  to  be  managed  from  a  platform-centric  perspective,  which  limits  their  utility  to  the  BF 
at  large.  Additionally,  both  the  sensors  and  communication  links  have  inherent  physics-based 
bounds  that  limit  their  area  of  coverage  and  accuracy — and  which  presents  limits  that  the  SRM 
must  work  within. 
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-  Supports  Planning/ Force  Mgt; 


-  Deployment 
-  Movement 
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action,  enemy  order  of  battle  info 


CTP  ~  Near-Real  Time  (seconds} 


-  Supports  Cueing/Force  Mgt; 

-  Maneuver 

-  Asset  Control 

-  Weapon/ Sensor  Cueing 
-  Target  Weapon  Pairing 
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Figure  5  -  Three  Realms  of  BF  Information 
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In  order  to  achieve  information  superiority,  the  BF  must  ensure  consistency  between  the  three 
information  realms.  For  example,  a  decision-maker  may  detect  differences  in  the  location, 
status,  or  characterization  of  a  target  as  it  is  represented  in  the  COP  and  in  the  CTP.  This  is 
likely  caused  by  time  lateness  and  observation  of  different  time  frames.  Since  the  pictures  are 
updated  at  different  rates,  data  may  be  available  for  the  CTP  that  are  not  yet  available  to  the 
COP.  Without  implementing  the  SRM,  achieving  consistency  between  the  information  realms  is 
a  serious  challenge.  Thus  collapsing  the  information  realms  is  both  an  enabler  of  SRM  as  well 
as  a  result  of  SRM. 


Automated  Intelligent  Link  Management 

An  important  enabler  of  network-centric  sensor  management  is  the  automated  control  of  data 
distribution  throughout  the  BF.  Major  bandwidth  constraints  exist  due  to  the  physical  limitations 
of  the  BF’s  communication  devices.  These  limitations  prevent  the  paradigm  of  wasteful 
transmission,  or  the  sending  and  receiving  of  all  data  and  information  amongst  the  BF  platforms 
or  decisions  nodes  (which  would  be  a  great  enabler  of  cooperative  inter-platform  sensor  control). 
To  most  effectively  utilize  the  bandwidth,  the  BF  must  intelligently  distribute  data  and 
information  between  decision  nodes  based  on  the  needs  of  the  BF  information  users,  which 
dynamically  change  as  the  operations  and  missions  unfold. 

The  BF’s  tactical  information  users  consist  of  human  operators  and  decision-makers  as  well  as 
automated  C4ISR,  combat,  and  resource  (i.e.,  sensor)  management  systems  that  have  tactical 
roles.  As  missions  change  in  priority  and  existence  during  the  course  of  operations,  the  needs  of 
such  BF  tactical  information  users  change.  For  example,  during  remote  engagements,  the 
Cooperative  SRM  will  require  interplatform  throughput  priority  for  FCP  data  to  support  the 
closing  of  the  fire  control  loop.  Another  example  is  when  a  user’s  CTP  needs  change  according 
to  mission  priorities,  such  as  the  need  for  higher  resolution  subsurface  tactical  data  when  a 
subsurface  threat  is  detected. 


Automating  the  exchange  of  BF  information  to  meet  the  dynamically  changing  user  needs  is  key 
to  addressing  this  challenge.  The  establishment  of  an  intelligent  data  distribution  capability 
relies  on  automation,  since  the  timeframes  required  to  support  the  distribution  of  COP,  CTP,  and 
FCP  are  too  fast  and  the  amount  of  data  and  information  is  too  large  to  permit  a  manual  solution. 
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Figure  6  -  Intelligent  Link  Resource  Management  Concept 
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The  intelligent  data  distribution  concept  (as  illustrated  in  Figure  6)  is  based  on  an  automated, 
distributed  link  resource  management  system  that  places  a  smart  processor  (or  link  manager)  at 
each  decision  node  or  participating  platform.  Each  link  manager:  (1)  determines  the  needs  of 
the  information-recipient  users  or  decision  nodes;  (2)  keeps  track  of  what  data  and  information  is 
available;  (3)  determines  the  feasibility  of  transmission  (whether  the  decision  nodes  are  within 
transmission  distance,  whether  the  communication  links  can  support  transmission,  whether  the 
transmission  will  support  the  user’s  timeline,  etc.);  (4)  sends  commands  to  other  link  managers 
within  the  BF  to  control  and  manage  transmissions  and  transmission  modes;  and  (5)  transmits 
data  and  information  as  required. 


A  possible  solution  for  managing  links  under  such  a  paradigm  would  be  to  establish  transmission 
modes  such  as  one  based  on  the  three  information  realms  (COP/CTP/  FCP).  As  platforms 
information  needs  change,  the  transmission  modes  change  in  response.  For  example,  a  platform 
in  the  midst  of  an  engagement  might  invoke  the  “FCP”  transmission  mode  that  tailors  the 
information  update  rate,  bandwidth  usage,  and  transmission  direction  on  all  remote  links  that  can 
contribute  to  the  engagement.  Figure  7  illustrates  a  simplified  version  of  this  concept.  This 
illustration  shows  link  managers  handling  a  variety  of  different  user  information  needs  during  a 
snapshot  in  time.  The  link  managers  establish  link  modes  that  support  the  information  needs, 
which  vary  across  platforms.  In  Figure  7,  the  links  are  shown  in  bold  that  provide  data  to  the 
platform  that  requires  FCP  data.  The  BF  communication  architecture  would  be  optimized  to 
support  the  FCP  user’s  needs  as  a  higher  priority  than  the  other  platforms  during  this  time  period. 
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Figure  7  -  Intelligent  Link  Resource  Management  Concept 


Automating  the  SRM  Operator’s  Interaction 

This  section  addresses  methods  for  managing  sensor  resources — studying  three  levels  of 
automated  HIL  methods  as  illustrated  in  Figure  8.  In  a  fully  manual  HIL  system,  the  human 
operator  performs  all  decision-making  functions  without  the  aid  of  an  automated  display.  In  the 
semi-automatic  sensor  system  (shown  in  both  Figures  8  and  9),  which  is  most  characteristic  of 
current  Naval  approaches,  the  machine  processes  and  fuses  sensor  data  and  even  supports  fire 
control.  Yet,  in  this  model,  the  human  controls  the  sensor.  The  operator  forms  an  integral  link  in 
providing  feedback  between  tracking  performance  and  future  sensor  behavior.  In  today’s  Naval 
BF,  sensor  control  best  fits  the  semi-automatic  model  for  controlling  search  volumes  and  areas. 
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(overriding  automated  decisions). 


Figure  8  -  Human-in-the-Loop  Models 


In  the  automatic  sensor  system  (shown  in  Figures  8  and  9),  an  automated  sensor  manager 
controls  the  sensor  based  on  inputs  from  automated  processes  (such  as  data  association,  fusion, 
and  situation  assessment)  and  from  the  human  operator.  In  this  configuration,  the  automated 
sensor  manager  provides  the  primary  feedback  to  the  sensor  under  the  possible  guiding  input 
from  the  Operator.  Thus,  the  automated  sensor  manager  is  responsible  for  controlling  future 
sensor  behavior  while  the  operator  exercises  control  by  negation.  Today’s  Naval  BF  uses  this 
model  during  weapon  engagements.  The  sensor  is  controlled  automatically  for  cueing  and 
establishing  track  and  providing  updates  to  the  interceptor. 

Semi-Automatic  Sensor  System  Automatic  Sensor  System 


Figure  9  -  Semi-Automatic  &  Automatic  Sensor  Systems 


Clearly  as  the  level  &  amount  of  both  data  and  processed  information  increases,  the  ability  of 
operators  to  make  decisions  decreases.  Selecting  the  correct  HIL  model  (or  correct  level  of 
automation)  is  a  design  imperative.  The  semi-automatic  system  is  best  suited  for  simpler 
operational  environments  that  contain  fewer  and/or  slower-moving  targets  that  are  easier  to 
track,  thus  reducing  the  amount  of  information  that  the  Operator  must  deal  with  and  simplifying 
the  Operator’s  decisions.  The  automatic  system  is  more  costly  to  develop  and  maintain — thus  it 
should  be  employed  only  when  the  operational  needs  and  environment  dictate — such  is  the  case 
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for  the  Naval  BF  with  missions  such  as  Anti-Air  Warfare.  The  following  benefits  that  can  be 
yielded  from  implementing  an  automated  sensor  manager  are  necessary  for  the  Naval  BF: 

•  Reduced  pilot  workload  -  automated  manager  alleviates  the  need  for  the  operator  to  specify 
each  sensor  operation  or  future  behavior.  Operator’s  role  can  become:  override  a  track’s 
priority,  establish  degree  of  allowable  active  radiation,  request  special  data  collection,  etc.) 

•  Sensor  Tasking  based  on  finer  detail  -  Operator’s  control  ability  is  based  on  information 
shown  on  display  and  ability  to  assimilate  information  into  human  decision-making  process. 
This  limits  the  amount,  types,  and  degree  of  detail  of  information  feeding  the  sensor  control 
decisions.  Automating  sensor  tasking  allows  more  amounts,  types,  and  finer  degrees  of 
detailed  information  to  support  the  decision-making  process,  (i.e.,  humans  much  better  at 
tactical  objectives  than  making  decision  concerning  the  fine  details  of  sensor  operation) 

•  Faster  Adaptation  -  automated  feedback  allows  much  faster  adaptation  to  the  changing 
environment,  i.e.,  earlier  detection  of  tracking  performance  degradation. 

IV.  Payoffs  of  Cooperative  Sensor  Resource  Management 

Realization  of  the  full  benefits  of  BF  sensor  resources  can  only  be  attained  through  collaborative 
inter-platform  war  fighting  schemes — or  achieving  the  network-centric  paradigm.  The  BF  must 
be  viewed  as  a  single  integrated  combat  system  of  systems,  rather  than  a  collection  of  loosely 
connected  surface,  subsurface,  and  air  platforms.  When  BF  system  thinking  is  adopted,  the  focus 
shifts  from  legacy  stovepipe  systems  and  platforms  with  little  or  no  collaboration  incentive,  to 
optimized  uses  of  resources  that  transcend  platform  boundaries  and  span  multi-threat 
dimensions.  Achieving  a  BF  system  and  reaping  the  full  benefit  afforded  by  distributing  BF 
resources  on  geographically  disparate  and  movable  platforms  may  be  possible  by  dedicating 
further  analysis  to  the  concepts  presented  in  this  paper.  Further  study  of  intelligent  inter¬ 
platform  data  sharing,  increased  levels  of  BF  automation,  and  introducing  a  COP/CTP/FCP 
shared  BF  information  database,  in  addition  to  developing  the  Cooperative  SRM  concept  in  more 
detail  is  key  to  envisioning  and  eventually  achieving  the  network-centric  paradigm. 

Expected  payoffs  of  achieving  network-centric  sensor  resource  management  include: 

Increased  Battle  Space  Picture  Accuracy  -  the  SRM  is  expected  to  increase  target  track 
accuracy  and  improve  interoperability  problem  that  inhibit  inter-platform  picture 
synchronization. 

Decreased  Degraded  Coverage  Zones  -  the  SRM  is  expected  to  decrease  “degraded”  or  “no 
coverage”  surveillance  zones. 

Improved  Surveillance  Coverage  -  the  SRM  is  expected  to  increase  the  detection  range  of  the 
BF. 

Decreased  BF  Reaction  Time  -  the  SRM  is  expected  to  decrease  the  average  BF  reaction  time 
(aggregate  time  taken  by  BF  surveillance,  command,  control,  and  communications  systems  in 
responding  to  an  attack). 

Optimized  Economy  of  Resources  -  the  SRM  is  expected  to  better  utilize  sensor  resources  an 
avoid  redundancy  and  non-use  by  allocating  tasks  to  sensors  optimally. 

Enabled  Innovative  Inter-platform  Sensor  Usage  -  the  SRM  is  expected  to  enable  new 
sensor-weapon  pairings  (i.e.,  remote  engagements),  avoid  legacy  stove-piped  sensor-weapon 
pairings,  and  inter-platform  sensor  operations  that  would  otherwise  not  be  possible  or  imaginable 
within  narrow  decision-making  time-lines. 
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The  achievement  of  the  Cooperative  SRM  supports  BF  interoperability  and  information 
superiority.  It  ultimately  results  in  the  ability  to  make  earlier  decisions  based  on  more  accurate 
data  and  faster  and  more  accurate  responses  to  the  ever-growing  threat  space.  The  Cooperative 
SRM  enables  and  encourages  the  collaboration  that  leads  to  a  single  integrated  BF  system  of 
systems — all  of  which  result  in  battle  space  gains. 
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